The present invention relates to inter RAT (Radio Access Technology) handover in a communication network. Within the scope of 3GPP E-UTRAN, also referred to as Long Term Evolution, LTE, standardization, solutions for Inter RAT handover have been agreed. As used herein, E-UTRAN denotes the cellular radio system developed and standardized by 3GPP, and eNodeB (eNB) denotes a E-UTRAN radio base station node. Such eNodeB could serve multiple E-UTRAN cells.
Functionality to handle user mobility is a fundamental component in cellular networks. From a service quality perspective, such functionality must ensure that service continuity is maintained as users of wireless communication devices move from one cell to another during an active session, and that each new session is established in a sufficiently good radio environment. From a spectral efficiency perspective, such functionality should ensure that an active user is always served by the most appropriate remote radio unit or units, such as an eNodeB for E-UTRAN or an RNC (Radio Network Controller) in UTRAN, which often means the closest remote radio unit, in a radio sense. Thus a handover may have to be performed from time to time, for example as a wireless communication device move between different cells in order to avoid call termination when the wireless communication device gets outside the range of the first cell.
A UTRAN to E-UTRAN Inter RAT handover procedure takes place when the network decides to perform a handover. The decision to perform PS handover from UTRAN to E-UTRAN is taken by the UTRAN Serving RNC (SRNC) and this decision could be based on radio condition measurements reported by a User Equipment, UE, to the SRNC.
The 3GPP TS 23.401, chapter 5.5.2.2, gives an overview of the handover preparation and handover execution signaling at handover from UTRAN to E-UTRAN.
Before deciding of handover to E-UTRAN, the SRNC will check that UE is E-UTRA capable. In addition, such UE may be configured by the SRNC to perform measurements on E-UTRA cells, and for that purpose compressed mode (dependent on UE capability) might have to be configured. Compressed mode is needed when making measurements on another frequency (inter-frequency) or on a different radio technology (inter-RAT). In the Compressed Mode the transmission and reception are stopped for a short time while the measurements are performed on other frequency or RAT in that time. After the measurements are over the transmission and reception resumes. To make sure that the data is not lost, the data is compressed in the frame making empty space where measurements can be performed.
This implies that when a handover is initiated, this has been preceded by a number of steps taken, such as radio resource reconfigurations, measurement reconfigurations, measurements and measurement reports. If the handover to E-UTRA is not allowed for some reason, those steps would be wasted. Instead, other alternative steps (e.g. measurement on other radio technologies, other UTRA frequencies) could have been inhibited while the UE is configured to do measurements on E-UTRA cells. Due to possible UE limitations and/or UTRAN limitations, the SRNC has to select what action to take when the UE measurement result received from UE indicates e.g. bad radio conditions in current UTRA cell/frequency. In addition, when a handover is initiated for radio condition reasons the handover must have high probability for success; otherwise the call might be dropped.
A user operating in a UTRA access system may for example have either a GSM subscription with a UMTS Integrated Circuit Card, UICC, of type SIM (GSM Subscriber Identity Module), or a UMTS subscription with a UICC of type USIM (Universal Subscriber Identity Module). Depending on UICC type, different Authentication and Key Agreement, AKA, algorithms are used. The AKA procedure runs between the Serving GPRS Support Node, SGSN, and the UICC in the UE. It is the SGSN that initiates the AKA procedure and it is normally done at each attach, i.e. each first registration in the serving network, for example at power on. An AKA procedure could also be performed when the UE is already attached. A typical case is at Routing Area update in a new SGSN. The type of AKA performed depends on the security information the SGSN is receiving from the user's HLR/AuC (Home Location Register/Authentication Center) of the user's Home Environment. The security information received from HLR/AuC contains a ciphering key Kc if the user has a GSM subscription, while it contains a ciphering key CK and an integrity protection key IK if the user has a UMTS subscription. At the GSM AKA, which is supported by UICC of type SIM, the ciphering key Kc (64 bits) is generated by the SIM. At the corresponding UMTS AKA, which is supported by UICC of type USIM, the ciphering key CK (128 bits) and the integrity protection key IK (128 bits) are generated by the USIM.
The different AKA algorithms, e.g. the different keys generated and the length of the security keys, gives that the security level for a UE equipped with a UICC of type SIM is considered to be lower than when equipped with a UICC of type USIM.
The SGSN initiates the relevant AKA towards the UE based on information received from the user HLR/AuC (Home Location Register/Authentication Center). The AKA procedure is performed with signaling between UE and SGSN and transparent through UTRAN.
The ciphering and integrity protection of user and control data is performed between UE and SRNC, i.e. the ciphering and integrity algorithms are allocated to UE and SRNC.
The ciphering and integrity protection algorithms, defined for UTRA access, uses security keys of length 128 bits. In order to give support for a user having a GSM subscription (SIM) to get services also in UTRAN, there are two 3GPP defined conversion functions that derives the UMTS ciphering and integrity protection keys (CK and IK) from the 64 bits GSM cipher key (Kc) according to the following, where c4 is the conversion function to obtain CK and c5 is the conversion function to obtain IK:CK[UMTS]=Kc∥Kc;  (c4)IK[UMTS]=Kc1xorKc2∥Kc∥Kc1xorKc2;  (c5)whereby in c5, Kc1 and Kc2 are both 32 bits long and Kc=Kc1∥Kc2.
Thus, when a user/UE with GSM subscription, i.e. holding a UICC of type SIM, is attached to a UTRAN, the UE derives the UMTS ciphering and integrity protection keys CK and IK that are valid for UTRA access from the GSM cipher key Kc using the conversion functions c4 and c5. The security keys are used for the ciphering and integrity protection of user data and control signaling sent between the UE and the SRNC.
The same conversion functions are used by the SGSN. For a UE in connected mode, these derived CK and IK are sent from SGSN to the SRNC when to request start of the ciphering and integrity protection between UE and SRNC.
The 3GPP TS 33.102 gives more detailed information on security functions in UMTS.
3GPP Release 8 does not support any services in E-UTRA to UEs that are not equipped with a UICC of type USIM. Thus, if a UE that has E-UTRAN capability, but is not equipped with a USIM, it will not indicate any support for E-UTRA in its capability information that is sent to the UTRA network. As a consequence, UTRAN will not request the UE to do any E-UTRA measurement and it will not request the UE to perform handover to E-UTRA. Thus, in 3GPP Release 8, a UE without USIM is prevented handover from UTRAN to E-UTRAN because the UE disables its E-UTRAN capability as described in above. This disabling implies that although the UE is capable of E-UTRA access, when it is equipped with a UICC of type SIM it will already at attach inform the network about that it is not E-UTRA capable. This will then not change as long as UE is attached.
However, in 3GPP Release 9, IMS emergency bearer services are supported for both normal service mode and limited service mode UE, i.e. irrespective of which type of UICC the UE is equipped with, or if the UE does not have a UICC at all. The 3GPP SA WG1 LS document R2-094143 Reply LS to R2-094107 on “UICCless UE access for IMS emergency call in Rel-9”, states that a UE without USIM making IMS emergency call should be allowed handover from UTRAN to E-UTRAN.
Different solutions to achieve such handover have been discussed (see R2-094569 “IMS emergency call handover from UTRAN to EUTRAN for USIMless UE”), as follows:
Alternative#1 is a network based solution where the SGSN informs the RNC whether the UE has a valid UICC, i.e. a USIM that allows handover to E-UTRAN for non-emergency calls or not. The RNC uses this information to decide whether to do handover to E-UTRAN for a USIM-less UE such that if the UE without USIM is involved in an IMS emergency call, it will allow the handover.
However, alternative#1 requires update of the signaling protocol (RANAP, 3GPP TS 25.413) between SGSN and RNC. The release 8 specifications are frozen, but an RNC based on release 8 protocol specifications should anyhow be able to support release 9 E-UTRA capable UEs.
Alternative#2 is a UE based solution where a USIM-less UE disables the Information Elements, IEs, ‘Support of Inter-RAT PS Handover to E-UTRA FDD’ and ‘Support of Inter-RAT PS Handover to E-UTRA TDD’, which are part of the UE capability information sent from the UE to the SRNC, and only enables them when emergency call is setup but disables them again when the emergency call is terminated. Thus, the USIM-less UE toggles its E-UTRAN capabilities based on the RRC states it is in and whether emergency call is present.
Alternative#2 might however cause a lot of signaling between UE and network due to the fact that the UE needs to send new UE capabilities to the network each time it will perform an emergency call and once again at the end of the emergency call. This might lead to inconsistency but also it will be an inflexible solution since in the future there might be other services than just emergency calls where handover to E-UTRAN can be made allowed. Thus there might be other needs and other types of restrictions in the future when the network (UTRAN) needs to know the UICC type.
Thus, a network solution is preferred, and if possible a solution that does not require any change of signaling protocols between network nodes.